Self-Introduction: Gerald (Jerry) Carter
by Gerald (Jerry) Carter
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Name: Gerald Carter (aka Jerry)
Location: Dadeville, AL, USA
Profession: Software Engineer
Samba Developer
Company: HP
Goals: To promote Samba of course :-)
Historical
qualifications: Samba Team member since '98
Acting release manage for 2.2
and 3.0 releases.
Why trust me? I control the key that signs
the Samba releases :-)
gpg fingerprint:
pub 1024D/D83511F6 2001-06-26 Gerald W. Carter <jerry(a)samba.org>
~ fingerprint = 2E2B 0D60 EA94 223A DF37 0465 211E EA31 D835 11F6
sub 1024g/1FB5F197 2001-06-26
ok. Seriously, I'm assuming that someone is already
doing packaging for Samba in Fedora but have not been
able to find the right person to talk to. I'm very
interested in build a working relationship with whomever
is managing the Samba packaging now, or I can take
it over.
- --
cheers, jerry
- ----------------------------------------------------------------------
Hewlett-Packard ------------------------- http://www.hp.com
SAMBA Team ---------------------- http://www.samba.org
GnuPG Key ---- http://www.plainjoe.org/gpg_public.asc
"If we're adding to the noise, turn off this song" --Switchfoot (2003)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQE/vlEjIR7qMdg1EfYRAoPJAKCK2tw2haBavv5rNiX1vqzsWlCedwCcD+N/
MA80UJMKn7hpl0ZArAnosqA=
=A88R
-----END PGP SIGNATURE-----
20 years, 5 months
Re: Fedora.us QA Queue
by Nils O. Selåsdal
On Fri, 2003-11-21 at 13:30, Michael Schwendt wrote:
> On Fri, 21 Nov 2003 09:35:29 +0100, "Nils O." Selsdal wrote:
>
> > One thing I'd like is to have the packages in CVS or similar..
> > So I easily could change the spec files or similar when QA'ing.
> > Often it's trivial or just some buildrequirements missing, and the
> > round trip time between QA and fixing things gets long.
> > But thats me.. And I guess ensuring the quality would be harder this
> > way ...
>
> CVS and automated build servers are in the works, but as long as no such
Ah. Didn't really know that.
> infrastructure is publicly available or even open for everyone,
> repository
> development can continue with what's available.
Ofcourse.
--
Vennlig hilsen/Best Regards
Nils Olav Selåsdal
System Engineer
UtelSystems a/s
Tlf: 370 45 431
Mob: 943 01 380
w w w . u t e l s y s t e m s . c o m
20 years, 5 months
Re: Fedora.us QA Queue
by Nils O. Selåsdal
On Fri, 2003-11-21 at 13:30, Michael Schwendt wrote:
> On Fri, 21 Nov 2003 09:35:29 +0100, "Nils O." Selsdal wrote:
>
> > One thing I'd like is to have the packages in CVS or similar..
> > So I easily could change the spec files or similar when QA'ing.
> > Often it's trivial or just some buildrequirements missing, and the
> > round trip time between QA and fixing things gets long.
> > But thats me.. And I guess ensuring the quality would be harder this
> > way ...
>
> CVS and automated build servers are in the works, but as long as no such
Ah. Didn't really know that.
> infrastructure is publicly available or even open for everyone,
> repository
> development can continue with what's available.
Ofcourse.
--
Vennlig hilsen/Best Regards
Nils Olav Selåsdal
System Engineer
UtelSystems a/s
Tlf: 370 45 431
Mob: 943 01 380
w w w . u t e l s y s t e m s . c o m
20 years, 5 months
Re: Fedora.us QA Queue
by Nils O. Selåsdal
On Fri, 2003-11-21 at 02:53, Michael A. Koziarski wrote:
> Hey guys,
>
> The fedora.us QA queue is very full right now. This potentially could
> discourage potential packagers as their shiny new packages languish on the
> queue. While obviously the ideal solution is hundreds of skilled &
> qualified QA people, the reality is that the numbers are lacking here.
>
> I'd like to propose a modification to the package submission procedure.
>
> The current system is:
>
> 1) New package submitted
> 2) QA
> 3) PUBLISH
> 4) PENDING
> 5) VERIFIED
> 6) CLOSED
>
> With the QA step, naturally, taking the longest. In order to keep the QA
> queue relatively clean, I'd like to see some kind of pre-QA keyword.
>
> What I'm envisioning here is a step to rule out packages that:
>
> 1) Don't build/install cleanly on the supported distributions
> 2) Sources can't be verified against upstream
> 3) Crash, print warnings or don't work when they are installed
> 4) Are duplicates
> 6) etc.
>
> By ruling out such simple errors the talented QA people can focus on
> things like packaging standards, spec file errors and other such
> complicated things. Whereas the enthusiastic-but-not-quite-there people
> (myself included) can help with the simpler errors.
>
> Also, by staying in the bug's CC throughout its submission process, the
> pre-QA team will see the kind of errors that they're missing and will
> slowly but surely make the transition to Fully Fledged QA.
>
>
> Comments? Flames?
One thing I'd like is to have the packages in CVS or similar..
So I easily could change the spec files or similar when QA'ing.
Often it's trivial or just some buildrequirements missing, and the
round trip time between QA and fixing things gets long.
But thats me.. And I guess ensuring the quality would be harder this
way ...
--
Vennlig hilsen/Best Regards
Nils Olav Selåsdal
System Engineer
UtelSystems a/s
w w w . u t e l s y s t e m s . c o m
20 years, 5 months
Fedora.us QA Queue
by Michael A. Koziarski
Hey guys,
The fedora.us QA queue is very full right now. This potentially could
discourage potential packagers as their shiny new packages languish on the
queue. While obviously the ideal solution is hundreds of skilled &
qualified QA people, the reality is that the numbers are lacking here.
I'd like to propose a modification to the package submission procedure.
The current system is:
1) New package submitted
2) QA
3) PUBLISH
4) PENDING
5) VERIFIED
6) CLOSED
With the QA step, naturally, taking the longest. In order to keep the QA
queue relatively clean, I'd like to see some kind of pre-QA keyword.
What I'm envisioning here is a step to rule out packages that:
1) Don't build/install cleanly on the supported distributions
2) Sources can't be verified against upstream
3) Crash, print warnings or don't work when they are installed
4) Are duplicates
6) etc.
By ruling out such simple errors the talented QA people can focus on
things like packaging standards, spec file errors and other such
complicated things. Whereas the enthusiastic-but-not-quite-there people
(myself included) can help with the simpler errors.
Also, by staying in the bug's CC throughout its submission process, the
pre-QA team will see the kind of errors that they're missing and will
slowly but surely make the transition to Fully Fledged QA.
Comments? Flames?
Cheers
Koz
20 years, 5 months
new package
by Zoltan Kota
Hi,
As I understood reeding some information on Fedora that new
programs/packages are also welcome in the project.
I have been involved in translation and rpm packaging of a nice
bibliographic program (working under gnome). A new stable release
was out recently. It would be very nice to see the program in the list of
fedora packages.
Could anybody tell me how to go on with this idea?!
Thanks
Zoltan Kota
20 years, 5 months