Hello,
although it might seem offtopic, but while talking about metadata.xml fileds
and `pkgdev bugs` I would like to ask opinions about have a metadata.xml field
that allows the maintainer to exclude the package from `pkgdev bugs`
That should be useful for core packages (gcc/glibc) and for pac
On Mon, Jul 17, 2023 at 19:39:30 +0300, Arthur Zamarin wrote:
> On 17/07/2023 16.50, Matt Turner wrote:
> > On Sun, Jul 16, 2023 at 2:04 PM Arthur Zamarin wrote:
> >> Now I'll speak from the point of implementer of `pkgdev bugs`. For me I
> >> think both approaches are good, but I would prefer the
On Mon, Jul 17, 2023 at 08:34:45PM +0300, Arthur Zamarin wrote:
> Hmm, I was thinking the opposite (maintaining it in parallel place to
> the package would be harder), but if you say so (and you help maintain
> huge clusters of packages so I believe you) then I think we don't have
> any good reason
On 17/07/2023 19.37, Sam James wrote:
>
> Big fan of the idea & very much in support of it. This also serves
> to give us logical groupings of packages which are closely related
> and should be bumped together.
>
>> There was some brief discussion on IRC about how to document these
>> groupings,
Matt Turner writes:
> Hello,
>
> Many of us have started using `pkgdev bugs` to file stabilization
> bugs. It works well (Thanks Arthur!) and I encourage everyone to give
> it a try.
>
> Where possible, it files one stabilization bug per package. This makes
> arch testers' jobs easier and makes
On 17/07/2023 16.50, Matt Turner wrote:
> On Sun, Jul 16, 2023 at 2:04 PM Arthur Zamarin wrote:
>> Now I'll speak from the point of implementer of `pkgdev bugs`. For me I
>> think both approaches are good, but I would prefer the latter over the
>> former. Nicer syntax, easy cache of all groups, ea
On Sun, Jul 16, 2023 at 2:04 PM Arthur Zamarin wrote:
> Now I'll speak from the point of implementer of `pkgdev bugs`. For me I
> think both approaches are good, but I would prefer the latter over the
> former. Nicer syntax, easy cache of all groups, easier to solve the
> "graph problems" in the t
On 16/07/2023 21.11, Ulrich Mueller wrote:
>> On Sun, 16 Jul 2023, Arthur Zamarin wrote:
>
>> - enables an easier syntax as `pkgdev bugs @group1` to file a single bug
>> for all of them. In Gnome's case as an example, we could have "gnome1",
>> "gnome2", "gnome3", "gnome4", etc - groups standi
> On Sun, 16 Jul 2023, Arthur Zamarin wrote:
> Let me list some things as advantages to each one (since I see an
> advantage to one as disadvantage to other).
> Advantages of field in metadata.xml:
> - local to package, easier to not miss. Easier to follow for the maintainer.
> - easier to
On 16/07/2023 17.57, Matt Turner wrote:
> Hello,
>
> Many of us have started using `pkgdev bugs` to file stabilization
> bugs. It works well (Thanks Arthur!) and I encourage everyone to give
> it a try.
Gladly :) You can semi-blame mgorny for the creation of `pkgdev bugs`,
because I started to fi
On Sun, Jul 16, 2023 at 11:15 AM Fabian Groffen wrote:
>
> On 16-07-2023 10:57:54 -0400, Matt Turner wrote:
> > Hello,
> >
> > Many of us have started using `pkgdev bugs` to file stabilization
> > bugs. It works well (Thanks Arthur!) and I encourage everyone to give
> > it a try.
> >
> > Where pos
On 16-07-2023 10:57:54 -0400, Matt Turner wrote:
> Hello,
>
> Many of us have started using `pkgdev bugs` to file stabilization
> bugs. It works well (Thanks Arthur!) and I encourage everyone to give
> it a try.
>
> Where possible, it files one stabilization bug per package. This makes
> arch tes
Hello,
Many of us have started using `pkgdev bugs` to file stabilization
bugs. It works well (Thanks Arthur!) and I encourage everyone to give
it a try.
Where possible, it files one stabilization bug per package. This makes
arch testers' jobs easier and makes the task easier to automate.
But som
13 matches
Mail list logo
