We are oil painting supplier

[ivan]

Hello!
We are a professional hand-painted oil painting manufacturer, located in 
Shilong Dongguan, China, the beautiful East River upstream. We are featured 
with handicraft oil painting, can produce various kinds of effects oil 
painting, plate painting, and famous painting reproductions.
We have skilled artists Nearly 50 more, can meet customers high-volume 
production, and the monthly production reached more than 5000pcs. Meanwhile, 
Every work should be carefully inspected and confirmed by artistic director 
himself before shipment, and never let go of any defects into the market, 
adhere to the fundamental principles of quality every place and any time. 
believe that our cooperation will let you be satisfied. welcome your inquiry 
and visit!

 

C&C ARTS CO.,LTD.
 OIL PAINTING FACTORY

Ivan 
 Skype:cca218
 Msn:jx_i...@hotmail.com
 E-mail:jx_i...@hotmail.com
 Add : No 18 Changmei street Xihu Shilong Dongguan Guangdong China

Re: DEP: 5 Machine-readable debian/copyright - License specifications - Link broken

[Ben Finney]

Scott Kitterman  writes:

> [the DEP 5 document states]
> "This is not a proposal to change the policy in the short term."
>
> Is the short term over or is the presence of this statement in Debian
> Policy (git anyway) merely ironic?

Neither. DEP 5 still does not change Debian Policy in any way.

-- 
 \  “In the long run, the utility of all non-Free software |
  `\  approaches zero. All non-Free software is a dead end.” —Mark |
_o__)Pilgrim, 2006 |
Ben Finney


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/871uvmn0ho@benfinney.id.au

Re: Report from the debconf11 sponsoring/mentors BoF.

[Serafeim Zanikolas]

David, thanks for the report.

Another issue that was mentioned during the Q&A is that debian-mentors is a
misnomer and should ideally be called smth like debian-packaging.
debian-mentors should become a discussion list for people that care about
mentoring in Debian.

Nitpicking aside, I care about mentoring but I don't have time for RFS calls
(other then the people I already sponsor) so it'd be wasteful to subscribe to
-mentors and I would rather have this discussion in -project instead.
I suspect I'm not the only one like that.

On Sun, Sep 11, 2011 at 08:44:23AM -0300, David Bremner wrote [edited]:
> Sponsor guidelines and tracking
> ---
> 
> Up to now, sponsor metrics do not exist yet. For now we rely on static
> lists, giving people hints whom they shall ask for sponsoring if the
> general RFS procedure on debian-mentors did not yield any success (or,
> also along the usual RFS procedure).
> 
> I (Arno) am currently staging a patch to Debexpo introducing limited
> support for sponsor metrics. It does not (and will not) feature the
> whole idea, but will allow developers, who are sponsoring packages to
> publish their personal sponsor guidelines in a more or less structured
> way. This will allow sponsored maintainers to learn about potentially
> interested developers more reasily, as the information is being coll-
> ected on a central, common place. Please stay tuned, I will announce
> this feature on behalf of the Debexpo team when it is deployed. Mean-
> while you are invited to test it and give feedback on it. Please
> contact Arno [6] if you want to have an exclusive look.
> 
> Please note, no further matching is effectuated, in particular we are
> not trying to guess the right sponsor for a package. A sponsored main-
> tainer is on its own to find the best sponsor for his package. Nonethe-
> less it is hopefully still an improvement and can be used as starting
> point for further work.

Arno, Janos (Cc'ed) expressed interest during DebConf in helping out as well,
but I haven't had the time to ping him about it.

I understand that there's two sides in this effort: debexpo plugins that
produce additional info about certain package features, and a repository of
sponsors' interests/preferences/requirements. Do I understand correctly that
you implement both things within debexpo? Are DDs expected to enter their
preferences via the debexpo web ui?

My idea instead was to maintain DDs' preferences via an ikiwiki instance
(using something structured like yaml), and make the wiki data accessible to
debexpo via a REST interface. At the end of the day, it's up to whoever will
do the work, but it's wise to remember that geeks prefer their favourite text
editor than a web browser.

Anyhow, thanks for stepping up, and whatever your approach, please share any
code you have with Janos and see whether/how you could work together.

cheers,
sez

-- 
Every great idea is worthless without someone to do the work. --Neil Williams


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110911215606.GD3458@mobee

Re: DEP: 5 Machine-readable debian/copyright - License specifications - Link broken

[Charles Plessy]

Le Sun, Sep 11, 2011 at 05:54:41PM -0400, Scott Kitterman a écrit :
> On Sunday, September 11, 2011 05:34:38 PM Charles Plessy wrote:
> ...
> > http://git.debian.org/?p=dbnpolicy/policy.git;a=blob;f=copyright-format/cop
> > yright-format.xml http://wiki.debian.org/PolicyChangesProcess
> ...
> 
> "This is not a proposal to change the policy in the short term."
> 
> Is the short term over or is the presence of this statement in Debian Policy 
> (git anyway) merely ironic?

The Debian Policy itself, which is the main document distributed in the
debian-policy package but not the only document, does not mention the DEP at
all.

While I have also objected having both works co-distributed, I now think
that the debian-policy package is a good place because we can take advantage
of it to easily publish the DEP and its revisions with the same mechanisms
as the sub-policies in “http://www.debian.org/doc/packaging-manuals/”,
and because the policy changes process is well suited to the maintenance
of a standard specification.

Have a nice day,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110911221519.gc4...@merveille.plessy.net

Re: DEP: 5 Machine-readable debian/copyright - License specifications - Link broken

[Russ Allbery]

Scott Kitterman  writes:

> "This is not a proposal to change the policy in the short term."

> Is the short term over or is the presence of this statement in Debian Policy 
> (git anyway) merely ironic?

It's not in the Debian Policy.  It's in the copyright format document,
which is not part of Policy, just managed as part of the debian-policy
package and via the same process.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/8762kyohrb@windlord.stanford.edu

Re: DEP: 5 Machine-readable debian/copyright - License specifications - Link broken

[Scott Kitterman]

On Sunday, September 11, 2011 05:34:38 PM Charles Plessy wrote:
...
> http://git.debian.org/?p=dbnpolicy/policy.git;a=blob;f=copyright-format/cop
> yright-format.xml http://wiki.debian.org/PolicyChangesProcess
...

"This is not a proposal to change the policy in the short term."

Is the short term over or is the presence of this statement in Debian Policy 
(git anyway) merely ironic?

Scott K


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201109111754.42053.deb...@kitterman.com

Re: DEP: 5 Machine-readable debian/copyright - License specifications - Link broken

[Charles Plessy]

Le Sun, Sep 11, 2011 at 09:45:18AM +0100, Lars Wirzenius a écrit :
> I'll note, in public, that after meeting with Steve in person, and
> having had a friendly and constructive discussion about DEP5 with him,
> I'll be stepping down from an active drivership role, at least for
> a while, and Steve will take care of getting any linguistic or other
> changes that he feels should be done, and push things through to a final
> version. Meanwhile, I'll ignore everything to do with DEP5.

Thank you very much Lars for all the time and efforts you put in this DEP.
Under your leadership, we made many progresses and are very close to
completion.

I do not think that we need a driver anymore for DEP 5.

DEP 5 is now integrated in the debian-policy package under the name
‘copyright-format’ and its modification now follows the same usual procedure as
the Policy itself.  Issues that are not done nor pending can be found in the
BTS by searching for the string ‘copyright-format’.

http://git.debian.org/?p=dbnpolicy/policy.git;a=blob;f=copyright-format/copyright-format.xml
http://wiki.debian.org/PolicyChangesProcess
http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=debian-policy;include=subject%3Acopyright-format

It has been proposed that upon release of the version 3.9.3.0 of the
debian-policy package, DEP 5 will be published somewhere on www.debian.org as
version 1.0 of the ‘copyright-format’ specification, and I have not seen
objections of principle against this.

I trust the Policy delegates to not release 3.9.3.0 before making sure that
there are no serious issues with the DEP, and think that the DEP can be marked
ACCEPTED after that publication.

BTS reports for language bugs in the current draft, especially significant
ones, are for sure welcome.  Peer review of the existing bugs – and by
extension all the 164 bugs of the debian-policy package – is also welcome, as
getting patches seconded by enough developers is sometimes a bottleneck.

Have a nice day,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110911213309.ga4...@merveille.plessy.net

Report from the debconf11 sponsoring/mentors BoF.

[David Bremner]

This report started as a summary from the sponsorship BoF held during
Debconf 11 in Banja Luka.  The full video stream is available on [0].
These were the major points, as interpreted by Arno Töll and David
Bremner.  As it was being written up, a few relevant things happened
with debexpo (mentors.debian.net) and/or were discussed on the list,
so we added some pointers to those as well.

Q: Why does Debian sponsor uploads?
- ---

Many present agreed that the main reason to sponsor uploads is
training.  New contributors need experience and training to get
packages in shape. Therefore the mentoring process can be seen as
incubator to develop new (uploading) Debian developers. One impression
to support this is that as new contributors tend to package software
for a fairly narrow target group.

On the other hand, several people outlined the technical benefit of
sponsoring packages, which is to get new software (typically that the
sponsors themselves consider useful or interesting) into Debian.
Similarly sponsors upload packages which have been orphaned by the former
maintainer.

Debian has several teams, at least some of which are highly effective
at mentoring, and all of which have more specialized expertise than
the debian-mentors mailing list.  In principle the mentoring process
should generally endorse people to join existing teams. This is
mutually beneficial, as new contributors learn best practices and
workflows while helping with the workload of teams.  Unfortunately
apparently [1] only 20% of all RFS requests appear to be related to
the work of existing teams.

Q: How are we doing, what could we improve?
- ---

Several problems were identified with mentoring process (or with the
experience of mentees). Broadly speaking these are in the (overlapping)
areas of making connections with sponsors, getting feedback, and
variability/fairness.

There was some discussion about how people have succeeded in finding
sponsors, and how sponsors like to be found. One or two people
mentioned only succeeding because of a pre-existing social
relationship. Most, but not all, sponsors preferred email over IRC as
a contact point.

Lack of feedback in the mentors process is a problem for several
reasons.  The current mentors process has a fairly large degree of
uncertainty.  Often it is unknown to sponsorees how they are doing as
there is no (visible) progress or feedback at all. This is
discouraging for new contributors.  In fact the mentors FAQ already
gives some ideas about what to do in this case (ask on IRC, ask again,
and so on). It isn't clear how much people read this FAQ, maybe some
automatic messages could be generated from mentors.debian.net with
hints about future steps.

Another, quite different problem with the mentors process is that it
seems based on the false assumption that every package belongs to
Debian.  Many packages are either too immature or don't add anything
really new to Debian.  We should be willing to tell people this,
rather than politely ignoring packages and hoping they go away.

Debian is supposed to be "Do-ocracy", in particular as many decisions
as possible are left to the individual developer. From the sponsoree
perspective the result is a bit chaotic: they hear different stories
about what is mandatory and what is suggested. There is also the
element of developer taste, which varies widely in terms of what
software they find interesting and worthwhile.  This can result in a
high quality package providing software for special interests gets
lost, while a less good package but targeting a more popular area of
interest is sponsored. There was no concensus about whether it was
possible (or desirable) to change these subjective aspects, but see
below for a technical proposal about matching packages and sponsors.

Recently, Michael Gilbert asked to switch the reviewing part of the
mentoring process to the Debian Bug Tracking Systems (BTS) [2]. If you
are sponsoring packages or being a sponsored maintainer, please tell
us your opinion here, as there are possible improvements over the
current procedure observable, as well as concerns. Help us to find
the best solution.

Q: Should there be a mentors team, or some other structure?
- ---

The discussion, whether there should be a "mentors team" can be seen
From two perspectives. First, one could see it as team which looks for
"lost and lonely" packages, and sees as last resort, whether it could
be uploaded to Debian. Generally this idea did not seem to attract many
persons in the audience.

Alternatively, this could be seen as collaborative maintenance team,
similar to the QA team (including its drawbacks), where sponsors and
maintainers get together to collectively improve packages. Some people
casted doubts on this idea as well, mentioning the QA team as refer-
ence, where everyone but effectively nobody feels responsible

Re: Report from the debconf11 sponsoring/mentors BoF.

[Paul Wise]

On Sun, Sep 11, 2011 at 1:44 PM, David Bremner wrote:

> Also it was discussued how to avoid follow-up RFS mails for successive
> uploads to the debian-mentors mailing list. Those are typically a sign
> of a non-functional mentoring process, as it implies that either the
> maintainer did not know about the suggested tight relationship between
> sponsor and maintainer, or the sponsor did not reply in time. In the
> first case the maintainer should learn about the whole concept of
> mentoring. Here, the Debian Women project was mentioned who apparently
> provide every new contributor a fixed mentor, e.g. similar to the
> application managers for NM. In the later case no obvious answer was
> found. Maybe a sponsor should not consider sponsoring a package, if he's
> conceivable short of time or unwilling to sponsor successive uploads.
> This is, because it leaves a contributor without possibility to maintain
> his own packages, without sponsor who would advocate him at some point
> to come over this problem and the software archive with
> old/outdated/buggy software.

I personally encourage people I have sponsored to send future RFS
mails to debian-mentors instead of me personally. I do this for two
reasons:

I prefer to do the sponsoring/mentoring work in public so that it
benefits other sponsees and provides example things for other sponsors
to check for or think about when reviewing packages. Also this way of
working is part of the culture of Debian and the spirit of our social
contract.

If I am busy then it gives an opportunity for other sponsors to look
at the package and provide reviews or uploading.

> Finally it can be observed many developers don't take part of the
> mentoring programme at all. This is something which can maybe be
> improved, once it is disclosed what discourages them from
> sponsoring. Several people confirmed they would start to sponsor
> packages again, once the metrics idea is implemented, as they are not
> willing to sponsor everything.

I would encourage developers interested in starting to do sponsoring
to join teams. Several teams use a tool called PET that mostly
eliminates the need for RFS mails since it provides a status/todo
board for all packages maintained by the team. The perl modules team
is probably the best example of this.

> I (Arno) am currently staging a patch to Debexpo introducing limited
> support for sponsor metrics.

Awesome!

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAKTje6EyXYT2eL4C6LLvE68oiPxjBjBjz4j0tQ9P=4eaxkj...@mail.gmail.com

Re: DEP: 5 Machine-readable debian/copyright - License specifications - Link broken

[Lars Wirzenius]

I'll note, in public, that after meeting with Steve in person, and
having had a friendly and constructive discussion about DEP5 with him,
I'll be stepping down from an active drivership role, at least for
a while, and Steve will take care of getting any linguistic or other
changes that he feels should be done, and push things through to a final
version. Meanwhile, I'll ignore everything to do with DEP5.

On Sat, Sep 10, 2011 at 02:12:31PM +0900, Charles Plessy wrote:
> Package: debian-policy
> Version: 3.9.2.0
> Severity: minor
> Subject: [copyright-format] correct or add links to SPDX.
> 
> Dear all,
> 
> I attached a patch that corrects or adds links to the SPDX Open Source License
> Registry.

-- 
Freedom-based blog/wiki/web hosting: http://www.branchable.com/


signature.asc
Description: Digital signature